Thanks @bishabosha ! Lets get your mainargs changes landed, that way we can cut a release and you can test your WIP in CI

+1 for switching over to using directives!

• Support an alternative to $-imports #3062

@lihaoyi see com-lihaoyi/mainargs#148

[Edit: after switching to depending on mainargs 0.7.2] in https://github.com/com-lihaoyi/mill/actions/runs/10418081276/job/28853542122?pr=3369 you can see integration tests like example/tasks/6-workers/local passing

Rebased and included the new mill-moduledefs 0.11.0-M1

@lihaoyi just recording here that the mockito third party test can be flaky (specifically StubbingLookupListenerCallbackTest.add_listeners_concurrently_sanity_check):

https://github.com/mockito/mockito/blob/1e337ed703ce2b78ce9ea40ff8b8c645f8219cf2/src/test/java/org/mockitousage/debugging/StubbingLookupListenerCallbackTest.java#L199-L202

as seen in the CI run https://github.com/com-lihaoyi/mill/actions/runs/10909315276/job/30277476457?pr=3369#step:9:4941

@lihaoyi is there any updates to the plan for merging this post 0.12.0?

@bishabosha let's hold the PR open for now, going forward I can take over responsibilities for keeping the PR up to date so you don't need to maintain it forever.

I don't know exactly how much development we'll see in 0.12.x yet, so not sure when the best time to break bincompat in main will be, but I expect there'll be some short-term follow up from the 0.12.0 release.

1. Keeping the PR open and occasionally merging main into it would be isomorphic to merging it, cutting a 0.12.x release branch, sending PRs to the release branch and then doing batch-merges into main.

2. Either of those options would probably be less tedious than having to backport every PR if 0.12.x is still under active development

3. But keeping the PR open and updated is probably going to be less confusing than cutting/targeting 0.12.x and batch-merging into main

So for now I think it makes the most sense to keep the PR open and periodically merge main into it until we're ready to break bincompat. I can do the work of keeping it up to date with main going forward

Seems that OS-Lib 0.11.4-M2 is causing an unreasonable compile time slowdown in Scala 3 so sticking with 0.11.3 for now. Probably a consequence of com-lihaoyi/os-lib#329

merged in latest main and got most tests passing; there are still some stragglers but nothing blocking.

The main thing still missing is proper support for corrected line-numbers and file-names. This kinda-sorta works in certain cases and not others, e.g. sourcecode.Line and sourcecode.File gives the wrong values still

@lihaoyi maybe you can cherry-pick my plugin fixes from https://github.com/bishabosha/mill/tree/scala3-build-sc-reintroduce-linenumbers and https://github.com/bishabosha/mill/tree/scala3-build-sc-reintroduce-linenumbers-with-dotc-patch

From Scala 3.6.2 the backend will accept the line number fix from a plugin without needing hacks

Also I heard that the restriction on pre-typer plugins could potentially be lifted for non .scala files, if one were to make the PR to scala/scala3 - unsure if .sc still applies

All tests are green. Probably more polish to do esp.w.r.t. error locations, and will need a few more rebases, but hopefully not too many before we merge this in January